From Saturday, Nov 23rd 7:00 PM CST - Sunday, Nov 24th 7:45 AM CST, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Data Acquisition Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

How feasible is the idea of setting up an open source driver project? This would be something that NI could host, but anyone could participate in to build a driver that can fit into different platforms. It can build on the DDK driver, but be centralized for collaborative effort. I like the name Open-DAQ driver. This would be a good way to address Linux users who are accustomed to source code. I know we have a DAQmx Base as a separate driver for different platforms, but an open source project would allow the Linux community to build a solution for novel or unusual Linux versions.

Dear NI, please consider a future hardware feature addition:

 

Add a "Power Up Delay DIP Switch" to the back of the PXI Power Supply Shuttle.

 

It would allow end users to reliably sequence the powering-up of multi PXI chassis solutions. It could also be handy to sequence any other boot-order sensitive equipment in the rack or subsystem. This would also be a world-voltage solution since this capability already exists in the power shuttle. We are seeing the need for more input-voltage-agnostic solutions. I'm sure you are too.

 

It might offer time delay choices of 1,2,4,8,16 seconds, etc.

 

We run into this problem on every multi-chassis integration. We have solved it several ways in the past like: human procedure (error prone), sequencing power strips ($$$ and not world-voltage capable), custom time-delay relays ($$$).

 

Imagine never having your downstream chassis(s) disappear. Or worse yet, having them show up in MAX, but act strangely because of not enough delay time between boots.

 

Thanks for reading this, and consider tossing me a Kudos!

 

 

Hello everybody,

 

I use always MAX to configure my DAQ cards to remove the burden of writing every time the same code just to create a DAQ task. MAX is part of my LabVIEW tool base and every project where I use a DAQ card does have a MAX config file.

 

Everything is nice, until I have to add some third party hardware! Then I have either use the driver provided with the hardware or write my own driver. I cannot use MAX to configure it, therefore I have to write VIs to allow online configuration. I also have to write VIs to load and save the configuration of the hardware. It would be much simpler, if the supplier of the third-party hardware or I could write plug-ins for MAX (and DAQmx) to incorporate the hardware in LabVIEW (and of course other software, which uses MAX). I could use the same API for nearly all of my hardware. One example from a competitor for this kind of hardware integration is Ipemotion of Ipetronik. There is even a plug-in for DAQmx in Ipemotion!

 

Regrads,

Marc

NI support for or something similar from NI's ecosystem, partners, a consortium...

 

http://www.edn.com/article/CA6676166.html?nid=3351&rid=14771462